Software defined networking, SDN, is an approach that basically relates to decoupling the management and controlling tasks from data packet forwarding tasks. The management and controlling tasks are usually referred to as “control plane” whereas the forwarding tasks are referred to as “data plane.” This decoupling can simplify the structure of a network and can standardize interfaces between individual components and between the control plane and data plane. Usually, the data plane is configured such that it necessarily requires control commands from the control plane in order to handle the forwarding tasks. Simply speaking, the ‘intelligence’ of an SDN system is provided in the control plane whereas the data plane simply carries out commands and instructions received from the control plane. One mechanism which relates to and defines the communication between the control plane and the data plane is OpenFlow. It should be understood that any reference to OpenFlow in the following generally relates to any mechanisms and interfaces which define the communication between the control plane and the data plane in SDN. Reference to OpenFlow is made representative for any of these mechanisms and interfaces.
The future networks (both telecom and Internet) are going to support millions and millions (even billions) of sensors as well as users using applications that will require sending periodic or recurrent control or data messages from one node to another. The term sensor is used herein as an example for any data source. The forwarding of such data messages is performed by the data plane and the components of the data plane. The future networks may be SDN based.
As mentioned above, the SDN approach to network design and management separates the control plane from the data plane of the network and may centralize the control plane to a logically single controller. An SDN network may be composed of simple switches (or forwarding elements) in the data plane and at least one intelligent SDN controller that configures how those switches behave by installing flow (or forwarding) rules on the switches. Flow rules are generally composed of match-action-pairs. The header and/or other parts of an incoming packet may be matched and in case of a match the switch may trigger actions such as forwarding to a certain port number, dropping the packet altogether, forwarding to the controller and so on. In case an incoming packet doesn't match any of the flow rules defined on the switch then the switch can send what is called a PACKET Ind. to the controller. The controller may analyze this PACKET INT and install newer flow rules on the switches to handle future such packets. The switches may have a limited fast memory size for installing these flow rules called TCAM (Ternary Content Addressable Memory). The switch may store the less used rules in an auxiliary memory and fetch them to the TCAM only when a match happens.
The problem with supporting a high number of sensors or other periodic data/signaling connections is that rules for all those sensors cannot exist at the same time in the TCAM or even in the auxiliary memory. Typically then these messages will generate PACKET Ms to the controller every period for the end to end path setup that must be processed by the controller. This may increase the communication overhead between the control plane and the data plane and may thus lead to increased latency in the SDN system.
T. Mizrahi et al., Time-based Updates in OpenFlow: A Proposed Extension to the OpenFlow Protocol, Israel Institute of Technology, describes an extension to OpenFlow protocol that allows time-triggered configuration updates. Such extension aims at coordinating network updates across multiple devices, e.g. a controller sends update messages to several OpenFlow switches with the same scheduled execution time. The controller can also configure a time-based sequence of updates by sending k update messages with k different update times.
M. Al-Fares et al., Hedera: Dynamic Flow Scheduling for Data Center Networks describes a dynamic flow scheduling system that efficiently utilizes aggregate network resources. In this solution, a central scheduler, based on regular updates of current network-wide communication demands, calculates the proper embedding of current flows in order to maximize the utilization of global network resources. Current flows can be moved to alternative paths if needed.
U.S. Pat. No. 8,824,274 relates to scheduled network layer programming within a multi-topology computer network. A Path Computation Element installs forwarding information to network nodes at the scheduled time for a scheduled path. This is a general path computation element, PCE, path reservation approach, wherein the reservation is done at a scheduled time in the future according to wishes of the application.